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DETAILED ACTION 
Response to Remarks 

1 . The applicant's arguments and amendments filed on November 28, 2005 have been 
carefully considered but they are not deemed fully persuasive. The discussion of Applicant's 
arguments follows. 

Claim Rejection - 35 U. S. C. 102 

The applicant's argument are threefold (1) that Gross is silent concerning the limitation 
"changing ownership of information stored in each of the plurality of disks to an un-owned state" 
and "changing ownership of information stored in each of the plurality of disks to a state of 
destination file server ownership." (2) Grossman teaches away from the "changing ownership 
information stored in each of the plurality of disks" and (3) Claims 10-15 are not substantially 
the same as claims 1-3, because the claims 14 and 15 cite "predetermined sector of the disk" and 
"a changing small system interface level 3 reservation of the disk. 

In response to the applicant's first argument, the Examiner directs applicant's attention to 
the operation of vgexport and vgimport. Contrary to what the applicant suggests (i.e., vgexport 
does not modify the ownership information on the disks), vgexport does modify the disks that are 
exported; it writes such information to the disks. See the example source code listing for 
vgexport, given in the document vgexport.c. The source code is part of an open-source logical 
volume manager library available for Linux and it explains what functions vgexport implements. 
The document is not relied upon as prior art, but as evidence in support of the view that vgexport 
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writes "ownership" information to the disks. In the document vexport.c, see the static function 
vgexport_single, which includes vg_write(vg). The function vg_write writes "ownership" 
information "vg" to the disks. 

The logical volume manager (LVM) on Linux implements the representative functional 
capabilities of other UNIX flavors of LVM. 

As for the applicant's second argument (i.e., Gross teaches away from the changing 
ownership information"), the Examiner notes that the applicant misinterprets the Grossman's 
statement "volume group information and data is untouched on the physical volume." What 
source code listing shows is that the volume group information and data are not modified, but the 
ownership information (e.g., See vg->status != EXPORTED_VG in vgexport.c) is indeed 
modified. 

The applicant's third argimient is that the limitations "predetermined sector of the disk" 
and "a changing small system interface level 3 reservation of the disks" have not been 
considered. The Office's response is that they have been considered, and these limitations do not 
add substantively to the claims, thus, the claims 14 and 15 cite substantively the same limitations 
as the claims 1-3. 

As for "predetermined sector of the disk," the Examiner notes that the adjective 
"predetermined" is ambiguous. It is not clear when the sector is "predetermined." If the sector 
is predetermined prior to the removal of the ownership, then, Grossman's vgexport meets the 
requirement. The sector, to which data is written, is certainly "predetermined"; it is computed 
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before the ownership information modification. In addition, the "sector" is applicable to every 
disk that is manufactured. In summary, the phrase "predetermined sector of the disk" does not 
add any meaningful limitation as it is applied to vgexport. 

As for "changing small system interface level 3 reservation of the disks" is not mentioned 
or defined in the specification; it is meaningless in the context of the claim. The limitation 
"means for changing small computer system interface level 3 reservation of the disk to an un- 
owned state" just translates to "means for changing disk to un owned state," again, which has 
been discussed in the context of claims 1-3. 

In view of the above, contrary to the applicant' assertion "Gross is legally insufficient to 
anticipate the present claims under 35 U. S. C. 102, the Examiner is compelled to sustain the 
original grounds of rejection. 

Claim Rejection of claims 4-7 under 35 U. S. C. 103 
(a) Reliance on Inherency. 

The applicant argues, "it is improper to consider UNIX commands *vgremove' and 
'vgcreate' inherent to the cited references since they are not necessary part of these references. 
Indeed, there is no suggestion that the functionality of the commands is even applicable to the 
cited references." 

The Examiner maintains that vgremove and vgcreate are inherent part of a logical 
volume manager, which is part of Gross. All logical volume managers include the commands 
vgremove and vgcreate The Examiner directs the applicant's attention to the source file listing 
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for the logical volume manager, which includes vgremove and vgcreate. See "Contents of 
LVM2.201.15.tar." LVM2.201.15.tar is a listing of files that are included in the source 
distribution of logical volume manager. 

(b) Reliance of Ordinary Skill 

The applicant argues that the Examiner "appears to rely on 'ordinary skill' in the art, 
vsdthout citation to reference, in discussion of UNIX 'vgremove' and 'vgcreate' commands that 
allegedly make obvious the current claims." The point here seems to be that the applicant 
challenges "conimon knowledge" of vgremove of vgcreate, to which the Examiner must supply 
evidentiary support. 

A copy of source code for 'vgremove.c' and 'vgcreate' are provided to support the 
Examiner's contention. As it is plainly evident, they are part of LVM library that is common for 
implementing disk management system many variants. One of ordinary skill in the art would 
certainly be aware of its implementation techniques. 

To the applicant's argument that "without citation to documentary evidence the exact 
nature of the rejection is unclear," the Examiner notes that most UNIX flavors implement the 
same LVM core concepts and techniques. It does not matter which flavor of UNIX LVM the 
applicant cites. 

It is noted that the Examiner's arguments regarding vgremove and vgcreate are not based 
soley on the Examiner's experience, as the provided documentary evidence indicates. 
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(c) Reliance of the Prior Art 

In reference to claim 4, the applicant's argument here is that " 

while the Applicant claims steps for transferring ownership of a volume, Gross 
discloses (deleting) a logical volume with a UNIX "Ivremove" command. If a 
logical volume is deleted, all data in the volume is destroyed. Clearly, a deleted 
volume whose data has been destroyed may not thereafter be transferred in a 
transfer process. Further, Matsunami merely describes allocating and resizing 
storage areas on disks and is silent concerning transferring ownership in a transfer 
process [pg. 19, Remarks] 

In response, the Examiner notes that he claim says nothing about destroying or not 
destroying the information on the disks. It merely refers to changing the disk ownership, not 
information on the disks. Should the applicant wishes to argue the above point, the claim should 
cite the features in accordance with it. 

The applicant is missing the point of the rejection. The point here is that when one is 
manipulating disks using the logical volume manager, disks can be transferred from one server to 
another by issuing a series of commands. In fact, the commands exist precisely in order to 
facilitate one to redeploy disks of one server, when the disks are no longer used, for another 
server. 

Claims Rejections of claims 16-25 under 35 U. S. C. 103 . 

The applicant here repeats the arguments that have been presented before. They have 
been addressed above. 
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Claim Rejections of claim 8 under 35 U. S. C. 103 

As has been mentioned in the prior Office action, most of the limitations of claim 8 have 
been already discussed in reference to claims 4-7. Comparing claim 8 to claims 4-7 clearly 
shows that the limitations of claim 8 borrow from claims 4-7, 

The applicant's argument seems to be, in view of the above, is that Delaney discloses 
joumaling of changes to the file systems and storing a journal to media in general, but lacks 
teaching of how such joumaling could be used in a transfer of ownership of disks. 

Contrary to what applicant says, claim 8 does not relate how logging is related to the 
transfer of disks at all. It merely mentions that there are three loggings. 

As written, the claim thus reads on the combination of the cited references and Delaney, 
because the execution of any of the LVM commands within the journal file system would be 
accompanied by logging (i.e., 'joumaling') of any changes to the files. Such changes are not 
related to transfer of the disks, but nonetheless, "logging" (i.e., 'joumaling') exists. Note that in 
the combination, the logical volume manager commands would have been implemented using 
journal file system. 

To put it differently, claim 8 cites logging in addition to the limitations of claims 4-7, but 
does not indicate how that logging is related to change in file ownership. \ 

Claim Rejections - 35 USC §102 
2. The text of those sections of Title 35, U.S. Code not included in this action can be found 
in a prior Office action. 
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3. Claims 1-3, 9-15, and 26 are rejected under 35 U.S.C. 102(e) as being anticipated by 
Gross et al (Pat. No. 6,128,734, Gross hereinafter). 

With respect to claim 1, Gross shows a method of transferring ownership of a volume 
comprising the steps of 

changing ownership information stored in each of the plurality of disks to an un-owned 
state from a state of source tile server ownership [See vgexport command on lines 49-55, 
column 9]; 

changing ownership information stored in each of the plurality of disks to a state of 
destination file server ownership from the un-owned state [See vgimport command on lines 49- 
55, column 9]. 

With respect to claim 2, Gross shows the step of changing ownership of the plurality of 
disks to an un-owned state further comprises the steps of. 

changing a first ownership attribute of the disks to an un-owned state [See lines 55-60, 
column 9. The vgexport removes /dev/volume_group from /etc/lvmtab file]; and 

changing a second ownership attribute of the disks to an un-owned state [See lines 55-60, 
column 9. The vgexport removes the device files associated with /dev/volume_group from the 
system]. 

With respect to claim 3, Gross shows the step of changing ownership information stored 
in each of the disks to a destination file server further comprises the steps of 
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changing a first ownership attribute of the disks to a destination tile server state [See 
lines 1-12, column 10. The vgimport adds /dev/volume_group to /etc/lvmtab file]; and 

changing a second ownership attribute of the disks to a destination file server state [See 
lines 1-12, column 10. The vgimport adds the devices files associated with /dev/volume_group 
to the system]. 

With respect to claim 9, Gross shows a method of transferring ownership of a volume 
having a plurality of disks comprising the steps of: 

writing a first log file to record a first part of a transfer process; [The vgexport causes 
Ivmtab file to be rewritten. The first part of transfer process is therefore recorded in Ivmtab. The 
file system is no longer within the system; therefore it is in "un-owned" state. See lines 55-60, 
column 9] 

performing the first part of the transfer process , the first part of the transfer process 
being changing ownership informationed stored on each disk of the volume from a source server 
to an un-owned state [The vgexport removes device files. The removal causes the system to no 
longer "own" the file system, as the file system no longer exists on the server. See lines 55-60, 
column 9]; 

writing a second log file to record a second part of the transfer process [The vgimport 
causes /dev/volume_group to be written. File volume_group serves as a "log," which serves as a 
record of transactions. See lines 1-12 in column 10. Note that volume_group also serves as a 
configuration file] 
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performing a second part of a transfer process, the second part of the transfer process 
being changing ownership information stored on each from the un-owned state to a destination 
server. [The vgimport cause Ivmtab to be rewritten. The file system is imported, and is thus 
"owned" by the system. See lines 1-12, column 10] 

Claims 10-15 incorporates all the limitations of claims 1-3, but in computer product form 
and apparatus form rather than in method form. The reasons for the rejections of claims 1-3 
apply to claims 10-15. Therefore, claims 10-15 are rejected for substantially the same reasons. 

With reference to claim 26, Gross shows "the ownership attribute" is stored on a 
predetermined sector of each disk. As indicated in the above Response to Remarks, the feature 
is inherent in the vgexport or vgimport. Metadata information is stored on each of the disks. 
Too see this, examine the vgexport.c. One can see that vgexport invokes vg_write. Vg_write 
can be found in metadata.c. Looking at the source code, vg_write applies metadata to each of the 
"meatadata areas" (each of which are on disks). 

Claim Rejections - 35 USC § 103 

4. The text of those sections of Title 35, U.S. Code not included in this action can be found 
in a prior Office action. 

5. Claims 4-7 are rejected under 35 U.S.C. 103(a) as being unpatentable over Gross in vew 
of Matsunami et al (Pub No.: 2002/0099914, Matsunami hereinafter). 
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With respect to claim 4, Gross shows: 

sending a first message to a source file server, the message containing a request for 
transferring ownership of a volume of disks [ See Ivremove command on lines 35-38, column 4. 
The command is in UNIX. Removing the group removes the ownership of the volume, because 
it removes the volume]; 

receiving a response from the source file server [It is inherent in the execution of 
Ivremove command to give a response, which would then be transmitted back to the client]; 

if the response contains abort information, aborting the transfer [If the command were 
unable to execute, Ivremove has inherent capability of generating an error message, in which 
case any further steps for disk transfer cannot execute. The aborting capability (or sending an 
abort message) is inherent in Ivmremove]. 

if not, verifying that the volume can be transferred [Each LVM commands has internal 
error checking. When a string of them is executed, the last one serves as the step for "verifying." 
If any of the steps fails, the overall execution fails ("aborts")]; 

if the volume can be transferred, sending a second message to the source file server to 
perform the first part of a transfer process to transfer ownership from the source file server to an 
un-owned state [vgremove can be used, vgremove is one of the commands inherent in LVM]; 

receiving a response from the source file server after it performed the first part of the 
transfer process [the execution of LVM manager command, vgremove generates either error 
message or a successful return message. The feature is inherent in LVM.]; and 
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in response to the step of receiving, performing a second part of a transfer process to 
transfer ownership from the un-owned state to a destination file server [vgcreate is one of the 
commands inherent in LVM]. 

Gross does not show each of the above steps in combination. 

Matsunami, however, shows a network environment in which disk transfer maybe made 
from one server to another. 

It would have been obvious to one of ordinary skill in the art at the time of the invention 
to remove a set of disks from one server and to reallocate it to another, because the reallocation 
allows one to reuse disks. 

In addition, tt also would have been obvious to one of ordinary skill in the art at the time 
of the invention to sequence the steps given above in order to move physical volumes from one 
server to another. Moving the disks requires the following steps (which are the summary of the 
steps in the claim) to be executed in proper sequence. (1) transmission and reception of 
commands from a client station (2) the removal of all LVs (vgremove vnll generate an error if 
there are any logical volume which exists on the volume group) (3) the removal of the volume 
group and physical volumes, and (4) recreation of volume groups, using the same physical 
volumes, in another server. They must all be executed; otherwise, volimie transfer would not 
work. 

It would have been obvious to one of ordinary skill in the art at the time of the invention 
to use LVM commands (either inherent or otherwise) given in Gross with Matsunami' s system, 
because, as it is shown in Fig. 11, LVM (item 252) is part of Matsunami's system. The 
Management Console (301) can generate (either via scripting or user input) proper LV 
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commands to LVM on the server, to release the disks to be transferred, as explained for 
removing a volume and to install the disks on a different server. 

With respect to claim 5, Gross's LVM has commands that are inherent and meet the 
following limitations: 

changing a first ownership attribute of the disks to a destination file server state 
[vgcreate, part of LVM, creates the volume information on the disks]. 

Matsunami shows 

changing a second ownership attribute of the disks to a destination tile server state. 
Matsunami shows the feature that reads on "second ownership attribute." See WWN in Fig. 3 of 
Matsunami. It must be set to a new ownership value upon setting a new host server. 

With respect to claim 6, Matsunami shows steps of: 

verifying that the disks can be transferred in response to an initial request from a 
destination file server [The management console is opened at a server, as it can be at any 
terminal. See Fig. 7 for forming disk pool that can be used. The execution of the management 
console would send the first message from the server]; 

sending an acknowledgement by the source file server to the destination file server [See 
paragraph 0071 The server name is entered to LUN forming program interface, which 
communicates to the destination server]; 

receiving a second request from the destination file server [See paragraph 0071 . The 
server sends a response back]; 
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aborting if the second request contains abort information [The paragraph 0078 speaks of 
preventing access conflict]; 

changing the volume to an off-line status in response to the second request not containing 
abort information [Removing a volume group from the source server (See the discussion of 
claim 5, in reference to part of limitation that reads on Gross) makes it "off-line." ] 

performing a first part of a transfer process, the first part of the transfer process being 
transferring ownership of the source file to an un-ownd state [See the discussion of claim 4 
above in reference to part of the limitation that reads on Gross]; and 

sending a message to the destination file server to prompt a second part of the transfer 
process, the second part of the transfer process being transferring ownership from the un-owned 
state to the destination server [See 0095. Pool manager sends notice to the pool management 
agent. See the discussion of claim 4 for relevant part of the limitations that reads on Gross]. 

With respect to claim 7, Gross's LVM has commands that are inherent and meet the 
following limitations: 

changing a first ownership attribute of the disks to an un-owned state [pvremove 
removes the LVM information on the disk]. 

Matsunami shows changing a second ownership attribute of the disks to an un-owned 

state, 

Matsunami shows the feature that reads on "second ownership attribute." See WWN in 
Fig. 3 of Matsunami. See paragraph 0078, which talks about erroneous deletion. Upon deletion, 
WWN must be set to null to indicate availability. 
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6. Claims 16-25 are rejected under 35 U. S. C. 103(a) as being unpatentable over 
Matsunami, in view of Delaney et al. (Pub. No. 2003/009761 1, Delaney hereinafter) 

With respect to claim 16, Matsunami does not show, but Delaney shows, journal 
("writing changes to a log file"). The journal is written automatically for the changes that are 
made to the file system. 

Matsunami shows a method comprising: 

changing a first attribute of ownership firom source server ownership to an un-owned 
state by writing the change to a log file and rewriting the first attribute of ownership on the disk 
[vgremove command using LVM on Matsunami causes attached disks to be no longer associated 
with a server ("changing a first attribute of ownership firom source server ownership to an un- 
owned state"). Vgremove removes metadata actually on a disk to be removed. The erased ata 
contains physical volume information for the first server. The first physical volume information 
is "first ovmership attribute"]. 

changing a second attribute of ownership from source ownership to an un-owned state by 
writing the change to a log file and rewriting the second attribute of ownership on the disk 
[vgremove command using LVM on Matsunami causes attached disks to be no longer associated 
with a server ("changing a second attribute of ownership fi-om source server ownership to an un- 
owned state"). Vgremove removes metadata actually on a disk to be removed. The erased ata 
contains logical volume information for the server. The logical volume information is "the 
second ownership attribute"]. 
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changing the first attribute of ownership fi-om the m-owned state of ownership to 
destination server ownership by writing the change to a log file and rewriting the first attribute 
of ownership on the disk [vgcreate command using LVM on Matsunami causes attached disks to 
be associated with a server ("changing the first attribute of ownership from the un-owned state of 
ownership to destination server ownership"). Vgcreate writes metadata onto volume to be 
owned. The written data contains physical volume information for the server. The physical 
volume information is the "first ownership attribute"]; and 

changing the second attribute of ownership from the un-owned state to destination server 
ownership by writing the change to a log file and rewriting the second attribute of ownership on 
the disk [vgcreate command using LVM on Matsunami causes attached disks to be associated 
with a server ("changing the second attribute of ownership fi-om the un-owned state of ownership 
to destination server ownership"). Vgcreate writes metadata onto the volume to be owned. The 
written data contains logical volume information for the server. The logical volume information 
is the "second ownership attribute"]. 

It would have been obvious to one of ordinary skill in the art at the time of the invention 
to incorporate joumaling to recycle network disk drives, to reuse available disk resource, and 
therefore, to remove disks from one server and to move it to another. 

It would have been obvious to one of ordinary skill in the art at the time of the invention 
to incorporate joumaling (as shown in Delaney) to recycle network disk drives, so that the 
recycling process would be recoverable in case of failure. The whole purpose of having a 
joumal is to for recovery, as stated in Delaney paragraphs 003-004. 
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With regard to claim 17, Delaney speaks of recovery in the event of recovery using the 
log (See paragraph 003 and 004). Matsunami shows the basic framework for disk reallocation 
("transfer ownership.") 

It would have been obvious to one of ordinary skill in the art at the time of the invention 
to transfer ownership utilizing the log, because using Delaney and Matsunami, (1) one would be 
able to recover the system after a failure and (2) one would be able to repeat the earlier procedure 
of disk transfer using the recovered system. The motivation is simple: to complete the transfer of 
the disks that was attempted prior to the interruption caused by the failure. 

Claims 18 and 19 substantively incorporate the limitations of claims 16 and 17, but in 
apparatus form rather than in method form. The reasons for the rejections of claims 16 and 17 
apply to claims 18 and 19. 

In reference to claims 20, its scope is broader than that of claims 18. As shown by 
dependent claims 24-25, limiting "first computer" and "second computer" as "the source server" 
and limiting "third computer" and "fourth computer" as "destination server" will define a claim 
whose scope maps substantively to claim 18. Thus, the reasons for the rejections of claims 18 
apply to claims 20, 

Claim 21 substantively incorporates the limitations of claim 19. The reasons for the 
rejections of claim 19 apply to claim 21. 
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In reference to claims 22 and 23, Matsunami shows all of the elements of claims 22 and 
23, including the one "destination server" / "single computer." See Fig. 1. 

It would have been obvious to one of ordinary skill in the art at the time of the invention 
to return a given set of disks to a pool, and then, based upon later need, to reacquire the disks for 
other projects, for a single computer. The motivation for cycling resource is to maximize disk 
availability to servers that need them. 

Claims 24 and 25 substantively cite limitations that are broader than those of claim 18. 
The reasons for rejection of claim 18 apply to claims 24 and 25. 

7. Claim 8 is rejected under 35 U.S.C. 103(a) as being xmpatentable over Matsunami and 
Gross and further in view of Delaney. 

In reference to claim 8, except for the steps regarding log files, all of the elements of the 
claim have been discussed with respect to claims 4-7. 

Neither Matsunami nor Gross shows the following: 

writing a first destination log tile; 

writing a first source log file; 

writing a second destination log file; 

writing a second source log file; 

writing a third source log file; 

writing a third destination log file; and 



Application/Control Number: 10/027,020 Page 19 

Art Unit: 2143 

erasing the previously written logs, 

Delaney shows logging associated with volume creation and volume destruction. See 
paragraphs 003 and 004. In the preceding combination of Matsunami, Gross and Delaney, the 
log would be written at both the destination and the source servers and then erased when the 
written logs are filled up. 

It would have been obvious to one skilled in the art at the time of the invention to log file 
system transactions in a log file, because as Delaney explains in paragraph 002, the logging 
(journal) would make the system more reliable and stable in the event of a system problem. 

8. Claim 27 is rejected under 35 U.S.C. 103(a) as being unpatentable over Gross in view of 
Black (Pat. No. US 6,708,265). 

Gross shows a part of the second ownership attribute is a small computer system 
interface (SCSI) persistent reservation tag. Vgexport, vgimport and other LVM commands have 
a built-in locking feature. However, Gross does not show SCSI. 

Black shows LVM (a variant of UNIX) and SCSI (See lines 1-3, in column 7). 

It would have been obvious to one of ordinary skill in the art at the time of the invention 
to apply the LVM, as mentioned in Gross, to SCSI interface, including the locks. The motivation 
to use the locks is to prevent write inconsistencies when clients request multiple, concurrent disk 
write accesses. 
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The suggestion for using LVM together with SCSI is given in Black. See the discussion of LVM 
in the "Discussion of the Related Art." Black's system is all about LVM. Black mentions the 
use of SCSI in that context (See lines 1-3, in column 7). 
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Conclusion 

9. THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time 
policy as set forth in 37 CFR 1.136(a). 

A shortened statutory period for reply to this final action is set to expire THREE 
MONTHS from the mailing date of this action. In the event a first reply is filed within TWO 
MONTHS of the mailing date of this final action and the advisory action is not mailed until after 
the end of the THREE-MONTH shortened statutory period, then the shortened statutory period 
will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 
CFR 1 .136(a) will be calculated from the mailing date of the advisory action. In no event, 
however, will the statutory period for reply expire later than SIX MONTHS from the mailing 
date of this final action. 

10. Any inquiry concerning this communication or earlier commimications from the 
examiner should be directed to Ji-Yong D. Chung whose telephone number is (571) 272-7988. 
The examiner can normally be reached on Monday-Friday 9:30-6:00, 

If attempts to reach the examiner by telephone are imsuccessful, the examiner's 
supervisor, David Wiley can be reached on (571) 272-3923. The fax phone number for the 
organization where this application or proceeding is assigned is 703-872-9306. 
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Information regarding the status of an application may be obtained from the Patent 
Application Information Retrieval (PAIR) system. Status information for published applications 
may be obtained from either Private PAIR or Public PAIR. Status information for unpublished 
applications is available through Private PAIR only. For more information about the PAIR 
system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR 
system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). 



Ji-Yong D. Chung 
Patent Examiner 
Art Unit: 2143 
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